Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.92%. Comparing base (710ee46) to head (6d5e1e5).
Report is 2 commits behind head on master.

@@           Coverage Diff           @@
##           master     #599   +/-   ##
=======================================
  Coverage   97.91%   97.92%           
=======================================
  Files          19       19           
  Lines        3262     3272   +10     
=======================================
+ Hits         3194     3204   +10     
  Misses         68       68           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Would it be too radical to remove si here and let those who care about state use DF2TFilter? Otherwise:

• I think something like a public zerosi would be better since it might help users get some idea of the dimensions of the state, although dispatching on say ::ZeroSI does strike me as more aesthetic.
• The change to returning a tuple with the state is sufficiently breaking, so preserving backwards-compatibility for not mutating state here isn't so important imo, but see below
• I feel passing in a single state for multiple columns is convenient and should be kept. But if so, the state passed in has different dimensions and it doesn't make sense to mutate it, hence it might be inconsistent if we only mutate si in the case of multidimensional input + state...

Would it be too radical to remove si here and let those who care about state use DF2TFilter?

I've been wondering the same. I'll give it try and open an alternative PR if it looks promising. EDIT: PR up at #603.

• I think something like a public zerosi would be better since it might help users get some idea of the dimensions of the state, although dispatching on say ::ZeroSI does strike me as more aesthetic.

Another point in favor of a zerosi would be a use-case where you do block-wise processing in a for-loop. It would be inconvenient (or type-unstable) to have to special-case the first-block to feed in a place-holder state. Better to allocate the state using a dedicated function before the loop.

• The change to returning a tuple with the state is sufficiently breaking, so preserving backwards-compatibility for not mutating state here isn't so important imo, but see below

Right. That would allow the return-type to remain the same, but then this might be silently breaking, i.e. the same code still works, but produces different results. We might want to avoid that. Also, filt should probably still not mutate the state, which asks for yet another entry-point which mutates the state, but contrary to filt! allocates the output. This sounds less attractive the more I think about it, maybe getting rid of si in favor of DF2TFilter really is the way to go.

• I feel passing in a single state for multiple columns is convenient and should be kept. But if so, the state passed in has different dimensions and it doesn't make sense to mutate it, hence it might be inconsistent if we only mutate si in the case of multidimensional input + state...

We could make that orthogonal by introducing some state-setup function that could both play the role of zerosi or do the appropriate repeat dance to fan out a single input state for multiple signals.

Superseded by #603.